Version 1

Communication

• determine if our current set of install locations is good: Standard JIL Install Location
  • Sam and Stephen have been asked to check with their sys admins about these locations

• ask admins we are working with what they use for installing applications on all of their computers.
  • Sam and Stephen have been asked to check with their sys admins

Installer

• update the bitrock installer so a better message is shown if the user can't install it globaly

• update the scripts for caching the resources of a otml file so it caches them in the format of the URL cache.
  • these scripts are currently written in ruby and have been used to make offline versions of activities.
  • if they are run in JRuby then they can use the same code used by the url caching mechanism.
    • AU: currently it's in pure ruby and generating the structure itself. once the Java caching mechanism is moved out of the otrunk project, it will be easier to include it in the install builder directories to be used in jruby.

• try building sample UDL bitrock installer from the command line on OS X
  • The command-line is simple. On my system it looks like:
    Unable to find source-code formatter for language: shell. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml

    bash$ /Applications/BitRock\ InstallBuilder\ Enterprise\ 6.1.3/bin/Builder.app/Contents/MacOS/installbuilder.sh build udl.xml osx
    bash$ /Applications/BitRock\ InstallBuilder\ Enterprise\ 6.1.3/bin/Builder.app/Contents/MacOS/installbuilder.sh build udl.xml windows
    

• setup an scripted process for building an installer, for now it will need to run on OSX:

  To generate all of the installers for all projects for windows and osx:

  • svn co https://svn.concord.org/svn/projects/trunk/common/java/deploy/bitrock-installers
  • cd bitrock-installers
  • ./build-all.sh /path/to/bitrock/binary
  • it needs
    • jnlp file(s)
    • otml file(s)
  • it then should
    • use jnlp2shell to cache the jars for the jnlp file and the jnlp file itself
    • use the resource finding scripts and the url cache to cache all of the resources
    • run the bitrock installer builder for windows and OS X
    • use hdiutil to make a disk image of the OS X installer
      • AU: If the build system is OSX, and the target system is OSX, it will create a dmg-wrapped version of the installer app in addition to the plain .app installer

Boot.jar (jnlp2shell.jar)

• update LaunchJnlp so it can find the install folder using same logic as described at the bottom here: Standard JIL Install Location
  • this requires passing the following sys props to LaunchJnlp: vendor, product_name, product_version

• update LaunchJnlp so if it can't find install folder it opens a url. The url should be passed in via a system property perhaps something like: not_installed_url
  • the url can be opened using a jnlp service.

• update LaunchJnlp so it sets a system property to tell the url caching mechanism where to look for the cache. This should be set to a subfolder of the install folder.
  • The url caching mechanism is InstallationResponseCache. You can use InstallationResponseCache.installResponseCache(File) to set the resource cache location – by default the "resources" directory in the install directory.

• update LaunchJnlp so it reads in a properties file in the install folder which can be used to set default system properties.
  • if a system property is already set by the wrapping jnlp then the install folder system properties should not override it.

• 7/20/2009: update Jnlp2Shell so it unzips the native jars, each into its own folder. And then adds this folder to the java.library.path

• 7/20/2009: update Jnlp2Shell so it has the option to store the cache using shorter paths. This can be done by hashing the URL and using that hash as the file name. If this is done then it is convenient to also store a file which records the mapping from URL to hash.

• update Jnlp2Shell so system properties set in the wrapped jnlp do not override system properties which set in the wrapping jnlp.

Misc

• update the SailDataEMF code so it looks for a system property which sets the location of the SailUserData folder.

• create a web app which dynamically generates wrapper jnlps
  • AU: This is now available at http://jnlpwrapper.diy.concord.org/
  • it has a set of template jnlps, (one for each project UDL, RITES, ER)
    • right now there's only one template, which gets modified on the fly based on url parameters
  • a template jnlp is referenced and passed the wrapped jnlp as a parameter.
  • something like this

http://jnlpwrapper.concord.org/udl-wrapper.jnlp?target=http://jnlp.concord.org/dev/org/concord/maven-jnlp/udl-otrunk/udl-otrunk-0.1.0-20090716.194157.jnlp

• add mechanism to investigation site to generate the wrapper jnlps.

Testing

• test the installer on windows 2000, XP, Vista and OSX 10.4 and 10.5
  • make sure to test it both with a user that has admin privledges and one that does not.

• test running a wrapped jnlp on all of the platforms above.
  • make sure to test some activity that uses native libraries to make sure that works

Extra Native Code

• try to find a way to deal with mozswing install
  • even the old mozswing can be pointed to a location with a system property or static method call. So there might be a straight forward way to do this.
  • One solution that works is to have the installer
    1. Copy the xulrunner contents to a folder
    2. Create a properties file under the product folder that sets mozswing.xulrunner.home to the xulrunner folder.

• try to find a way to deal with drivers install
  • examples of this are the LabPro drivers and ftdi drivers for dataharvest
  • it should be possible to integrate this with the bitrock installer.

Version 2

• update LaunchJnlp and URL Cache so they can handle having a read only global cache and a writable local/user cache.
  • Currently the URL Cache will always register a writable session cache, and then external classes can register read-only cache locations which will get included in the search.

• figure out how an admin will do an update of the installed files.

• figure out a better way for a user to have installers installed for multiple projects (RITES, UDL, and ER) with fewer duplicate files.

• update LaunchJnlp so it looks for a properties file in java.home which sets the root directory for the install folder. The Vendor and product would be appended to this folder to get the actual path.

• explore creating a package installer instead of using bitrock for OSX.
  • figure out if we can build package installers on linux